Boundaries vs. Targets: How to Set Hardware Product Specs That Empower Teams
The VP of Engineering looked exhausted. "Every time we update the cost estimate, the CEO asks why it changed. Every time we make a design decision, we're second-guessing whether it'll blow up the business case. We're paralyzed."
I see this pattern constantly. Capable teams, stuck. Not because they can't execute, but because nobody's clear on what's negotiable and what's not.
Leadership wants certainty. Engineers need room to solve problems. Every fluctuation feels like failure. Every decision requires approval.
The problem isn't the people. It's the structure.
Early in my career, I watched teams drown in this dynamic. Executives demanded cost targets. Engineers hit them on paper, then reality shifted. Designs matured. Quotes came back higher. Suppliers changed. Each variance triggered meetings, explanations, justifications.
When I finally led my first product end-to-end, I built a framework I've used ever since: Boundaries and Targets.
The Framework
It's simple. For any critical metric (cost, capital spend, schedule), you set two numbers:
Target: Aggressive but achievable. If you hit it, the business case sings.
Boundary: The upper limit. Cross it, and we stop everything for a reset conversation.
Between target and boundary? The team operates. They make tradeoffs. They solve problems. They don't need permission for every $0.50 variance.
At the boundary? We pause. Full transparency. Leadership and product team align on what's real, what's possible, and whether we keep going.
Most teams operate with only one number and treat every deviation as a crisis. Or worse, they have no agreed limits at all and drift until someone in finance notices months too late.
Why Teams Get This Wrong
Here's the thing nobody tells you about hardware development: Cost isn't a number. It's a moving target wrapped in uncertainty.
In the early days, your cost estimate is basically fiction. You're working from supplier estimates, paper calculations, and educated guesses. A component you think costs $5 might actually be $6.50 when you get a real quote. Or $3.80 if you find a better supplier.
As you build prototypes and run tests, the picture gets clearer. That mechanical design you thought was solid? Turns out it needs reinforcement, adding cost. But then manufacturing suggests a process change that saves money elsewhere.
By the time you hit production, you've converged on reality. But in the messy middle of development, you're constantly refining what "the cost" actually is.
Most teams pretend this uncertainty doesn't exist. They report a single number to leadership. Leadership anchors to it. Then every update feels like the team screwed up.
The boundary/target framework makes the uncertainty explicit. It gives the team room to navigate the fog without constant escalations.
How It Actually Works
When I set this up with a team, here's what changes:
We agree upfront on target and boundary. Leadership understands that between these two numbers, cost will fluctuate. That's not failure. That's development.
The team's job isn't to hit the target every week. It's to remove uncertainty faster than it accumulates.
Better quotes. Mature designs. Mitigate risks. Chase opportunities. Make smart tradeoffs.
As long as we're between target and boundary, they operate autonomously. No weekly cost reviews. No explaining every shift to executives. They have clarity on what's in bounds.
But the moment we approach the boundary, we stop.
Not because someone failed. Because we've hit a decision point that matters.
A Real Example
I worked with a team building a connected product. Smart people. Good product. Aggressive timeline.
The target cost was set based on competitive analysis. If they hit it, strong margins. The boundary was 15% higher. Leadership agreed that was the "we need to talk" line.
For six months, the cost bounced around. Sometimes closer to target. Sometimes drifting toward boundary. Normal turbulence. The team kept working.
Then they hit a problem. A sensor they'd spec'd wasn't performing. Two options:
Option A: Engineer around it. Cheaper sensor, keeps us under boundary, but adds three months and technical risk.
Option B: Upgrade to a better sensor. Pushes us over boundary by a few percent, but keeps schedule and reduces risk.
Time to stop.
We called the gate meeting. Full team, leadership in the room. No finger-pointing. Just transparency.
"Here's where we are. Here's why. Here are the options. Here's what we recommend."
Leadership had the context to make the call. They chose the expensive sensor. Crossing boundary by a small margin was worth it to preserve schedule and derisk the product.
But now we needed a plan. If we're over boundary, how do we get back?
The team went hunting. Found a mechanical redesign that simplified assembly. Negotiated better pricing on another component. Small wins that added up.
By production, they were back under boundary. Not at target, but close enough that the business case still worked.
The lesson: The boundary wasn't permission to stop caring about cost. It was clarity about when to escalate versus when to solve.
The team felt empowered. Leadership had visibility at the moments that mattered. No surprises. No death-by-meeting over small variances.
What This Means For You
If your hardware team feels stuck, ask:
Do we have both a target and a boundary?
Does the team know what's negotiable versus what requires escalation?
Are we treating cost as a fixed number or as something that converges over time?
Most teams either micromanage (every change needs approval) or under-manage (no clarity until it's too late).
Boundaries create clarity. Targets create ambition. Together, they create momentum.
The best teams aren't the ones that nail target on the first try. They're the ones that know when to push forward and when to stop and reset.
Does this resonate? Let's talk.
If your team feels capable but paralyzed by unclear decision rights, I can help. I work with teams to set up frameworks that empower execution while keeping leadership in the loop at the right moments.
